Final report #773
Final report #773
Conversation
dcoutts
requested review from
jorisdral,
mheinzel,
recursion-ninja and
wenkokke
as code owners
jorisdral
force-pushed
the
dcoutts/final-report
branch
from
e23d0e6 to
09e573a
Compare
jeltsch
force-pushed
the
dcoutts/final-report
branch
from
ba1d4ed to
a4b291e
Compare
Hmm, generated files shouldn’t be in a repository if the sources are there, right? We may easily get inconsistencies. We might put the generated PDFs at some sensible place on the web. Also generating them oneself shouldn’t be that hard. One needs Pandoc, of course, but that’s basically it. By the way, I recently added a makefile to |
jeltsch
force-pushed
the
dcoutts/final-report
branch
from
a34545b to
6538634
Compare
In theory no, in practice yes. It's for convenience of readers. They're simply not going to go generate the pdf. Not only does it involve installing pandoc, but also a dozen or more texlive packages. And apparently there's no way to declare which textlive packages are needed: one just has to iterate: make, fail, install, repeat. It's a 5 minute job at minimum (if you know how to do it), for something readers expect to take 1 second. |
Co-authored-by: Wolfgang Jeltsch <[email protected]> Co-authored-by: Joris Dral <[email protected]>
Using proper metadata, and use the same LaTeX margins, fonts etc.
The employed trick is to use no-break spaces, which is a hack but works.
No need to be .SILENT. It's helpful feedback to see what it did, what files it made.
Have to change the markdown format of the table to be able to use multi-row headers.
or snapshot open
in section on reproducing results
It makes more sense this way.
and its effect in the parallel scaling on the affected machines.
Use no disk caching, since that makes things more interesting. Use a much smaller write buffer. Otherwise the number of elements was 80k and the write buffer was a quater of that at 20k, which corresponds to just four runs. That doesn't allow for much run merging, which makes things less interesting. By using 1k for the write buffer, we get 80 runs inserted (or more for the benchmarks that use multiple iterations).
Admit we're just giving a high level summary and cite our own previous work for a full detailed treatment. Also improve the explanation of the pipelining diagram.
dcoutts
force-pushed
the
dcoutts/final-report
branch
from
0d0cded to
3430b87
Compare
|
I think we're done. Phew! |
Well, we could put the PDF files on the web, just not into the repository. I found GitHub Actions to be quite good for this, not least because it guarantees consistency between source and build product. That said, I don’t want to push anything for this particular case but just provide an idea. 🙂 |
The final write-up for the project.
We should probably also include .pdfs of some of the references (the preceding reports), and it'd probably be helpful to include a generated pdf of the final report and the integration notes.